🎯 Code Coverage (details)
• Patch Coverage: 80.49%
• Overall Coverage: 41.97% (-15.73%)

🟢 Java Benchmark SLOs — All performance SLOs passed

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

Commit: 869b8b72 · CI Pipeline · Benchmarking Platform UI

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

@codex review

💡 Codex Review

Snapshot the additional-tags configuration

When DD_TRACE_STATS_ADDITIONAL_TAGS is enabled, this getter re-queries ConfigProvider instead of returning an immutable value captured by the Config constructor. Consequently, mutable sources such as system properties can change this setting after configuration initialization, and the new setting is also absent from Config.toString() startup diagnostics. Store it in a final field during construction and include it in the configuration summary, as required for newly added configurations.

AGENTS.md reference: AGENTS.md:L37-L44

Preserve collapse deltas when the telemetry queue is full

When metricsQueue is full, this calls getValueAndReset() before discovering that offer() fails. TaggedCounter advances its previousCount during that call, so the rejected collapse delta is permanently lost instead of being retried on the next telemetry cycle; this is especially likely for these counters because they are collected after span and baggage metrics. Check queue capacity before draining or restore/re-add a rejected delta.

Reject unsafe additional-tag cardinality limits

When additional tags are enabled and DD_TRACE_STATS_ADDITIONAL_TAGS_CARDINALITY_LIMIT is set above 1 << 29, this value is passed directly to TagCardinalityHandler, whose constructor throws IllegalArgumentException; large values below that guard can instead attempt multi-gigabyte array allocations. Because this happens while constructing ClientStatsAggregator, a malformed setting can prevent tracer startup rather than falling back to the documented default. Validate a practical upper bound before constructing the schema.

Retain retired schemas until producers release them

If a producer reads the old peer-tag schema and is then paused for more than one reporting interval—for example during a long scheduling or GC pause—this reset discards previousPeerTagSchema before that producer queues its trace. When the delayed snapshots are eventually consumed, they update the retired schema's handlers, but no later cycle resets that schema, so any resulting peer-tag collapse counts are silently omitted from health metrics and the new telemetry counter. Retain retired schemas until delayed producers can no longer reference them, rather than for a fixed single cycle.

Thanks @codex. Reconciling against the current branch — this review was posted against c1916aa269, before the rebase onto the updated #11402 base and the follow-up commits:

1. Snapshot the additional-tags configuration (Config) — ✅ Fixed on base PR Add span-derived primary tags (CSS v1.3.0) #11402: traceStatsAdditionalTags is now a final field resolved in the constructor, returned directly by the getter, and included in toString() (f5b083bd80).
2. Preserve collapse deltas when the telemetry queue is full (CoreMetricCollector) — ✅ Fixed on this branch: prepareMetrics() now checks remainingCapacity() before getValueAndReset() and stops the stats drain early, so a full queue no longer resets a delta it can't enqueue; untouched counters are collected on the next cycle (545e3f03c9). The same guard for the pre-existing span/baggage loops is split out into Guard core-metric telemetry drain against queue-full delta loss #12081.
3. Reject unsafe additional-tag cardinality limits (ClientStatsAggregator) — ✅ Fixed on base PR Add span-derived primary tags (CSS v1.3.0) #11402: DD_TRACE_STATS_ADDITIONAL_TAGS_CARDINALITY_LIMIT flows through Config.getTraceStatsCardinalityLimit(...), which now rejects values above MAX_TRACE_STATS_CARDINALITY_LIMIT (1<<16) and falls back to the default rather than allocating oversized arrays or throwing during startup (4188b43471).
4. Retain retired schemas until producers release them (ClientStatsAggregator) — Known limitation, accepted by design. The retired previousPeerTagSchema is held for one reset cycle; the failure mode needs a peer-tag schema change (config / feature-discovery driven, rare) to coincide with a producer paused for more than a full reporting interval (~10s), and it affects only block-telemetry counts, never trace data. Retaining schemas until "no producer can reference them" would require producer-side liveness tracking we don't want on the hot path. Treating this as a pre-existing config-update race, not a Report stats span collapses over telemetry (client-side stats) #12070 regression.

Items 1–3 are resolved; item 4 is a documented accepted limitation.

To use Codex here, create a Codex account and connect to github.